REMARKS 



Claims 1-11 and 23-57 remain pending in the application. Reconsideration is 
respectfully requested in light of the following remarks. 

Section 101 Rejection : 

The Examiner rejected claims 47-57 under 35 U.S.C. § 101 because the claims are 

not directed to statutory subject matter. The Examiner states "according to Applicant's 

disclosure, page 39 lines 13-20, the computer-accessible storage medium is not limited 

[to] storage medium, instead it is defined to include both storage medium... and 

transmission medium." Page 39, lines 15-20 state (emphasis added): 

Generally speaking, a carrier medium may include storage media or 
memory media such as magnetic or optical media, e.g., disk or CD-ROM, 
volatile or non-volatile media such as RAM (e.g. SDRAM, DDR 
SDRAM, RDRAM, SRAM, etc.), ROM, etc. AS WELL AS transmission 
media or signals such as electrical, electromagnetic, or digital signals, 
conveyed via a communication medium such as network and/or a wireless 
link. 

Note that claims 47-57 have been amended to recite a computer-readable storage 
medium , and not a "medium" or a "carrier medium". Storage media are clearly 
described in the specification as encompassing tangible, physical articles or objects, 
("magnetic or optical media, e.g., disk or CD-ROM, volatile or non-volatile media such 
as RAM, ROM, etc,"), and thus storage media are statutory subject matter. Storage 
media are clearly differentiated in the specification from "transmission media or signals 
such as electrical, electromagnetic, or digital signals." 

Applicant refers the Examiner to Decision on Appeal 2007-2225 in the case of 
U.S. Patent Application 10/054,809, decided August 31, 2007. In the case, a similar § 
101 rejection of claims that recite a "computer-accessible storage medium" was appealed. 
The specification of U.S. Patent Application 10/054,809 includes the same verbiage as 
quoted above from page 39, lines 15-20 of the specification of the instant application, and 
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the Appellants provided a similar argument to that given above in a Reply Brief filed 
March 8, 2007. The Decision on Appeal reversed the § 101 rejection in that case. That 
Decision on Appeal is directly on point in this case. 

Thus, Applicant respectfully requests removal of the § 101 rejection of claims 47- 

57. 

Section 103(a) Rejection : 

The Examiner rejected claims 1, 2, 4-11 and 23-57 under 35 U.S.C. § 103(a) as 
being unpatentable over Lev Ran et al. (U.S. Patent 7,139,81 1) (hereinafter "Lev Ran") in 
view of Moore et al. (U.S. Patent 6,282,581) (hereinafter "Moore"). Applicant 
respectfully traverses this rejection for at least the following reasons. 

Regarding claim 1, contrary to the Examiner's assertion, the cited art fails to 

teach a remote procedure call system comprising a presentation block configured to 

present data types and Application Programming Interfaces (APIs) available to a 

program on the system. The Examiner relies on Lev Ran, and cites Lev Ran, col. 56, 

lines 12-67, Figure 12, col. 56, lines 19-25, col. 58, lines 40-67, col. 62, lines 5-16, and 

col. 56, lines 36-39. In particular, the Examiner appears to cite Application Transport 

Layer 46 as being equivalent to a presentation block. In col. 21, lines 21-33, Lev Ran 

discloses that an application transport layer 46: 

...provides services for activation of remote services and inter- VFN 
gateway communication. The remote services are used by adaptation layer 
45 and the higher transmitter and receiver application layers... 

In Col. 56, lines 6-11, Lev Ran further discloses that an application transport layer 

46: 

...is a framework for activating remote services used by the higher VFN 
application layers (adaptation layer 45 and VFN transmitter and receiver 
application layers 42 and 40). The application transport layer provides 
services that enable the different application layers to transfer data to 
and from one another . 
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Thus, it is clear that application transport layer 46 is a framework for enabling 
different components internal to VFN gateways 22 to transfer data to and from one 
another. In contrast, the presentation block recited in claim 1 is configured to present 
data types of and APIs to the remote procedure call system to a separate and distinct 
program on the system on which the remote procedure call system is implemented. 

In the Action dated May 15, 2007, in response to the above argument, the 
Examiner asserts "it is noted that the features upon which applicant relies (i.e., a 
presentation block configured to present data type and application programming 
interfaces to a separate and distinct program) are not recited in the rejected claim(s). . .A 
presentation block configured to present data type and application programming 
interfaces to a separate and distinct program has not been claimed and as such was not 
considered." Applicant notes that the Examiner should consider the claim as a whole. 
Claim 1 recites a system comprising a processor and a memory comprising program 
instructions executable by the processor to implement a remote procedure call system . 
The remote procedure call system as recited in claim 1 comprises a presentation block, an 
encoding block, a protocol block, and a transport block. The presentation block is 
configured to present data types and Application Programming Interfaces (APIs) 
available to a program on the system . A plain reading of claim 1 makes it clear that "a 
program on the system" is something other than the remote procedure call system itself, 
and is not included in the remote procedure call system, nor is it implemented by the 
program instructions that implement the remote procedure call system, and thus is not 
comprised in or by the remote procedure call system. Applicant's reference to "a 
separate and distinct [from the remote procedure call system] program on the system on 
which the remote procedure call system is implemented" does not require limitations 
from the specification to be read into the claim, as the Examiner wrongly asserts. 
Instead, Applicant is simply arguing the plain meaning of the claims. By stating that the 
remote procedure call system presents data types and APIs to a program , the plain 
meaning of the claim is clear that the program is separate and distinct from the remote 
procedure call system. If one thing presents something to another thing, then they are 
clearly two separate and distinct things. Again, Lev Ran's application transport layer 46 
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is not equivalent to a presentation block as recited in claim 1 of the instant application, as 
it is clear from the Lev Ran reference that application transport layer 46 is a framework 
for enabling different components internal to VFN gateways 22 to transfer data to and 
from one another. The "program on the system" recited in Applicant's claim 1 is not 
internal to the remote procedure call system of claim 1 per the plain meaning of the 
claim. Any other interpretation would not be consistent with the plain wording of the 
claim. 

The Examiner cites Lev Ran, col. 56, lines 19-25, and appears to assert that "RPC 

request messages" are equivalent to "[presenting] data types." The cited reference does 

not teach or suggest that RPC request messages are used to present data types available 

to a program on the system. The Examiner also cites Lev Ran, col. 58, lines 40-67, and 

states "java object. . .object class or type". It appears to the Applicant that the Examiner 

is equating "java object. . .object class or type" to "data types". Applicant notes that col. 

58, lines 40-67 is from a section of the Lev Ran reference titled "Encapsulation", a 

section describing the data encapsulation layer 164, which performs 

serialization/deserialization. Col 58, lines 53-54 disclose that: 

Each object class, or type , preferably has its own serializer and 
deserializer. 

Applicant fails to see how this citation has anything to do with presenting 
data types available to a program on a system. Lev Ran clearly does not teach or 
suggest that the application transport layer 46 presents "java object... object class or 
type" to a program on the system. 

In the Action dated May 15, 2007, in response to the above argument, the 
Examiner asserts "As for a remote procedure call system comprising a presentation 
block configured to present data type to a program, page 12 describes the presentation 
block as follows, 'Presentation 100 encompasses the data types that may be passed 
between remote systems...'. The 'java object/object class or type' passed in an RPC 
request/response as disclosed on column 56 lines 20-25 and column 58 lines 40-67 of the 
Lev Ran prior art is the data type passed between remote systems as the instant 
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specification discloses." As to Lev Ran, col. 56, lines 20-25, the cited reference does not 
teach or suggest that RPC request and RPC response messages are used to present data 
types available to a program on the system . The full paragraph that includes the citation 
reads as follows: 

Remote services are activated by bidirectionally transferring remote 
procedure call (RPC) messages between a client application transport 
layer ("RPC client") on one VFN gateway and a server application 
transport layer ("RPC server") on a second remote VFN gateway. 
Preferably, the application transport layer functions asymmetrically, 
whereby the RPC client sends RPC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
RPC client . RPC request messages include the request and any necessary 
parameters, and RPC response messages include any necessary return 
values, such as a file. RPC requests, RPC responses, parameters, and 
return values are preferably Java objects, in order to support Java-based 
implementations of the higher application layers. Alternatively, the 
application transport layer functions symmetrically, whereby in addition to 
the RPC client issuing requests to the RPC server, the RPC server can 
issue requests to the RPC client. In such a symmetric implementation, the 
RPC server can connect to the RPC client at a later time in order to 
respond to an earlier request from the RPC client. 

The purpose of the RPC messages as taught by Lev Ran is to "activate remote 
services." In Lev Ran, an RPC client on one VFN gateway and an RPC server on anther 
remote VFN gateway exchange RPC messages to "activate a remote service". Lev Ran 
simply discloses that "RPC requests, RPC responses, parameters, and return values are 
preferably Java objects, in order to support Java-based implementations of the higher 
application layers." The citation does not teach or suggest anything like the notion of a 
presentation block configured to present data types and Application Programming 
Interfaces (APIs) available to a program on the system . The presentation block as is 
recited in claim 1 has nothing to do with the exchange of RPC messages between a client 
system and a remote server. Indeed, in claim 1, it is clearly recited that the sending of 
messages to a "remote system" is handled by the transport block of the remote procedure 
call system, and not by the presentation block of the remote procedure call system. The 
presentation block is instead configured to present "data types and APIs" available to a 
program on the system . Furthermore, the "program on the system" in claim 1 is clearly 
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and distinctly a different entity than the "remote system" to which "encoded and protocol 
framed outgoing messages" are moved over an interconnect by the transport block . 



As to Lev Ran, col. 58 lines 40-67, Applicant again notes that col. 58, lines 40-67 
is from a section of the Lev Ran reference titled "Encapsulation", a section describing the 
data encapsulation layer 164 , which performs serialization/deserialization. This 
selection is not even describing Lev Ran's application transport layer 46, but is 
instead describing a different component of Lev Ran's system. In this citation, Lev 
Ran disclose that: 

As mentioned above, RPC parameters are preferably Java objects. Before 
a Java object can be sent to a remote application, it must be converted to 
an XML or binary representation. This conversion is commonly referred 
to as serialization, or "encoding." The XML or binary representation is 
passed to the remote application, which converts it back to the original 
Java object. This conversion back is commonly referred to as 
deserialization, or "decoding." RPC client 170 and RPC server 168 use 
serializers to perform encoding, and deserializers to perform decoding. 
Preferably, serializers and deserializers are Java objects that implement 
appropriate Java interfaces, as described below. 

Each object class, or type , preferably has its own serializer and 
deserializer. Data encapsulation layer 164 provides several generic 
serializers and deserializers for common object types, such as String, 
Integer, Float, Boolean, and byte[]. 

Applicant fails to see how this citation dealing with serialization/deserialization 
has anything to do with presenting data types and Application Programming Interfaces 
(APIs) available to a program on a system, as is recited in claim 1 . Lev Ran clearly does 
not teach or suggest that the application transport layer 46 presents "java object... object 
class or type" to a program on the system . Lev Ran instead teaches, in the first cited 
selection, that the application transport layer 46 on a client system and the application 
transport layer 46 on a remote server exchange RPC messages "to activate remote 
services", and that "preferably" Java objects are used in the message exchange "in order 
to support Java-based implementations of the higher application layers." The second 
cited selection, when discussing a different "layer" than the application transport layer 
46, simply describes the serialization/deserialization of "common object types". These 



10/677,434 (5681-64301/P9233) 



7 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



citations do not teach or suggest anything like a presentation block configured to present 
data types and Application Programming Interfaces (APIs) available to a program on the 
system, as is recited in claim 1 . 

The Examiner also cites Lev Ran, col. 62, lines 5-16, and quotes from that 
selection ". . .empty RPC request object. . .". It appears to the Applicant that the Examiner 
may be equating "empty RPC request object" to "data types". This citation is from a 
description of FIG. 14, which Lev Ran describes as "a method for processing an RPC 
request by [an] RPC client" (col. 62, lines 5-6). Note that the snipped quote from the 
section comes from a sentence reading in part "The RPC client requests an empty RPC 
request object c..." Applicant fails to see how this citation, in which an RPC client is 
described as requesting an empty RPC request object, has anything to do with presenting 
data types available to a program on a system. 

The Examiner also cites Lev Ran, col. 56, lines 36-39, and quotes from that 
selection Application transport layer 46 "...simple API...". A more complete context of 
that quote is: "The application transport layer provides a simple API to its highcr-lcvcl 
clients...". As noted above, it is clear from the Lev Ran reference that application 
transport layer 46 is a framework for enabling different components internal to VFN 
gateways 22 to transfer data to and from one another. Remote services are activated by 
transferring remote procedure call (RPC) messages between a client application transport 
layer ("RPC client") on one VFN gateway and a server application transport layer ("RPC 
server") on a second remote VFN gateway, not to a "program on the system". The 
higher-level clients of Lev Ran's application transport layer 46 are other layers and 
components of the VFN gateways 22 themselves, and not a "program on the system". In 
contrast, the presentation block recited in claim 1 is configured to present data types and 
APIs to the remote procedure call system to a separate and distinct program on the 
system on which the remote procedure call system is implemented. 

Thus, it is clear from the Lev Ran reference that application transport layer 46 is a 
framework that exposes interfaces to components of Lev Ran's VFN system internally to 
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other components of Lev Ran's VFN system. In contrast, the presentation block recited 
in claim 1 is configured to externally present or expose data types and APIs to the 
remote procedure call system to a program on the system that is separate and distinct 
from the remote procedure call system. 

In further regard to claim 1, contrary to the Examiner's assertion, the cited 

art fails to teach a remote procedure call system comprising a... protocol block 

configured to frame the encodings to denote the intent of the outgoing messages. The 

Examiner relies on Lev Ran, and cites Lev Ran, col. 61, lines 53-59 in support of this 

assertion. The Examiner appears to equate "RPC protocol manager" with protocol block 

as disclosed in claim 1 of the instant application. The citation provided by the Examiner 

states that RPC protocol manager 176: 

...handles network conditions (such as application failures, lost messages, 
out-of-order delivery, and method dependencies) in a generic manner. The 
RPC protocol manager includes, for example, a retransmission mechanism 
on the client side, and a response cache on the server side to aid in 
implementing at-most-once semantics for some requests. 

Applicant can find nothing in the above citation that teaches or suggests 
anything like a protocol block configured to frame the encodings to denote the intent 
of the outgoing messages . Lev Ran's RPC protocol manager "handles network 
conditions"; it is not described as performing any task similar to framfinsl the encodings 
to denote the intent of the outgoing messages . The only thing Lev Ran's RPC protocol 
manager 176 as described in the provided citation appears to have in common with the 
protocol block recited in claim 1 is that both include the word "protocol". 

In the Action dated May 15, 2007, in response to the above argument, the 
Examiner asserts "the instant application's specification describes the protocol block as 
follows: '...protocol 104 may frame the encoded data with the intent of the 
message... protocol 104 may interpret the intent... For example, response may be 
errors... protocol 104 may handle the error...' page 15 lines 26-29. The RPC Protocol 
Manager 176 of the Lev Ran prior art covers this limitation because it is used for 
determining when an error has occurred during RPC message communication, for 
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instance, application failure, lost messages and out-of-order delivery." The Examiner's 
assertion here has nothing to do with what is actually recited in claim 1 of the instant 
application in regards to the protocol block: a protocol block configured to frame the 
encodings to denote the intent of the outgoing messages. It is improper to rely on 
specific portions of the specification in isolation while ignoring the actual limitations of 
the claim . Again, Lev Ran's RPC protocol manager is described as "handling 
network conditions"; it is not described as performing any task similar to framfing] 
the encodings to denote the intent of the outgoing messages * the limtiation that is 
actually recited in claim 1. The only thing Lev Ran's RPC protocol manager 176 as 
described in the provided citation appears to have in common with the protocol 
block recited in claim 1 is that both include the word "protocol". The fact that the 
Examiner can find a selective quotation from Applicant's specification that describes 
"protocol 104" as handling at least some errors docs not overcome the fact that Lev Ran's 
"RPC Protocol Manager 176" is nowhere described as being configured to perform 
anything like framing the encodings to denote the intent of the outgoing message as is 
actually recited in claim 1 . The handling of errors by the protocol block is not recited as 
a limitiation in claim 1 of the instant application. The Examiner's assertion that "The 
RPC Protocol Manager 176 of the Lev Ran prior art covers this limitation because it is 
used for determining when an error has occurred during RPC message communication" is 
completely and totally without merit. 

Applicant notes that Application Transport Layer 46 and Adaptation layer(s) 45, 
as well as the other elements illustrated in FIG. 12, are components of VFN transmitter 
52 and VFN receiver 48, which are components of VFN gateways 22, which are in turn 
instantiated on VFN systems 20, which as noted above are clearly distinct from other 
clients and servers in Lev Ran's system (see, for example, FIGs 1 through 3). As noted 
above, the Lev Ran reference describes a Virtual File-Sharing Network (VFN) that 
enables client computers on one LAN to access files held by file servers on other LANs. 
The VFN comprises two or more VFN gateways , each of which is connected to a 
different LAN . The VFN gateways communicate with one another over the 
interconnection provided by the WAN. In order to serve a resource from a file server on 
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a first LAN to a client on a second LAN, the VFN gateway on the first LAN fetches the 
resource from the file server and transmits the resource over the WAN to the VFN 
gateway on the second LAN, which then serves the resource to the client. In contrast, the 
remote procedure call system recited in claim 1 of the instant application is described as 
being implemented in memory on a system, and as exposing APIs and data types to 
programs on the system . The remote procedure call system is configured to, on behalf of 
a program on the system , encode representations of the data types, frame the encodings, 
and transport the messages from the system to a remote system over an interconnect. 

In further regard to claim 1, contrary to the Examiner's assertion, the cited 
art fails to teach wherein the functionality of each said block is isolated from the 
functionality of the other said blocks in the remote procedure call system so that 
program instructions for each said block can be replaced or modified without replacins 
or modifying program instructions for any of the other said blocks . In fact, Lev Ran, 
for example in FIG. 12 and the discussion thereof beginning at col. 56, line 57 and in 
FIG. 13 and the discussion thereof beginning at col. 61, line 22, clearly discloses that Lev 
Ran's "application transport layer 46" comprises Lev Ran's "data encapsulation layer 
164", "transport layer 166", and "RPC protocol manager 176". Nowhere does Lev Ran 
teach or suggest that these various components ("layers" and "managers") are isolated 
from the functionality of the other described components of Lev Ran's system in such a 
way that program instructions for each (or any) o f the components can be replaced or 
modified without replacins or modifying program instructions for any of the other 
components. In fact, since Lev Ran clearly discloses that the "data encapsulation layer 
164", "transport layer 166", and "RPC protocol manager 176" are components of Lev 
Ran's "application transport layer 46", it would be impossible to replace or modify any of 
these components without replacing or modifying Lev Ran's "application transport layer 
46". 

In the Action dated November 1, 2007, the Examiner admits that Lev Ran is silent 
with reference to wherein the functionality of each said block is isolated from the 
functionality of the other said blocks in the remote procedure call system so that program 
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instructions for each said block can be replaced or modified without replacing or 
modifying program instructions for any of the other said blocks , and asserts that Moore 
teaches this functionality, citing Moore, "...dynamic...", col. 7 lines 40-49, 
"...dynamically...", col. 21 lines 30-36, and col. 22 lines 9-14. Applicants first note 
"each said block" and "other said blocks" refers to a presentation block , an encoding 
block , a protocol block , and a transport block of a remote procedure call system. The 
limitation in question is that the functionality of each of these blocks is isolated from the 
functionality of the other recited blocks in the remote procedure call system so that 
program instructions for each block can be replaced or modified without replacing or 
modifying program instructions for any of the other blocks. Examiner admits that Lev 
Ran does not teach this limitation. It is clear from the provided citations and from 
elsewhere in Moore that Moore also does not teach this limitation as recited in 
claim 1 . 

Col. 7, lines 40-49 of Moore reads: 

The present invention provides a communications framework for enabling 
processes in a distributed computing environment to use any of a number 
of communications protocols for remote method invocation on objects in 
other processes. The communications protocol actually used by the 
communications framework to effect a remote method invocation is 
transparent to the programs issuing the remote method invocation. 
Furthermore, the selection of a protocol is dynamic~i.e., which protocol is 
being used may change from one invocation of a remote method to the 
next. 

In this citation, Moore is describing a 'communications framework' that enables 
processes in a distributed computing environment to use any of several communications 
protocols for RMI on objects in other processes. FIG. 3 of Moore is "a block diagram 
showing the relationship of the communication framework of the present invention to 
other pieces involved in processing a remote method invocation." (Col. 7, lines 50-52). It 
is clear from this Figure and from the accompanying description starting at col. 7, line 50 
that Moore does not describe a remote procedure call system comprising a presentation 
block , an encoding block , a protocol block , and a transport block . Col. 7, line 63-col. 8, 
line 3 Moore defines an "RPC Transport": 
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The transportation of data between the applications 25 1 and these remote 
objects is accomplished via one of several communication protocols. 
Example communication protocols include ONC RPC, DCE RPC, 
CORBA HOP, SMTP, SNMP, HTTP, and Java/RMI. Corresponding to 
each protocol is a Remote Procedure Call Transport 305 (hereinafter, 
"RPCTransport"). 

It is clear from the above citation that each "RPC Transport" corresponds to a 
particular communication protocol. Thus, Moore's "RPC Transport" may encompass 
functionality similar to a protocol block as recited in claim 1, but not of the presentation 
block , encoding block , and transport block . Moore does not describe these other blocks 
in a remote procedure call system. 

Col. 7, lines 40-49 simply states "the communications protocol actually used by 
the communications framework to effect a remote method invocation is transparent to the 
programs issuing the remote method invocation ." In FIG. 3, these "programs" are 
represented by program 251a and libraries 251b. The citation says nothing about the 
functionality of each block in a remote procedure call system being isolated from the 
functionality of other blocks in the remote procedure call system so that program 
instructions for each block can be replaced or modified without replacing or modifying 
program instructions for any of the other blocks. Specifically regarding Moore's system, 
the citation says nothing about isolating functionality within Moore's communications 
framework as illustrated in FIG. 3 so that "program instructions for each block [within 
the communications framework] can be replaced or modified without replacing or 
modifying program instructions for any of the other blocks." Moreover, Moore does not 
even describe other blocks in a remote procedure call system. 

The Examiner calls attention to "...the selection of a protocol is dynamic -i.e., 
which protocol is being used may change from one invocation of a remote method to the 
next." Again, "one invocation" is referring to " a program issuing the remote method 
invocation ", and to the fact that Moore discloses a "communications framework" that 
makes particular communications protocols used in RMI transparent to programs that 
issue remote method invocations . 
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The Examiner also cites col. 7 lines 40-49, which reads: 

The decision logic may, for example, if the QoS provided by an 
RPCTransport 305 deteriorates during the course of the execution of a 
program, repeat the procedures of FIG. 13 and 12 at any invocation of a 
method of a remote object. By so doing, the decision logic can 
dynamically change which RPC Transport 305 and underlying protocol is 
used to effect the remote method invocation on an object. 

Col. 22 lines 9-14, also cited by the Examiner, simply discloses a specific 
technique to "dynamically replace communications protocols used by a process." These 
citations also say nothing about the functionality of each block in a remote procedure call 
system being isolated from the functionality of other blocks in the remote procedure call 
system so that program instructions for each block can be replaced or modified without 
replacing or modifying program instructions for any of the other blocks. Col. 7 lines 40- 
49 simply states that "decision logic can dynamically change which RPC_Transport 305 
and underlying protocol is used." In other words, the citations disclose only that Moore's 
system may dynamically switch between RPC transports, which may be roughly 
analogous to the protocol block recited in claim 1, but the citations are silent as to a 
presentation block , encoding block , and transport block as recited in claim 1 . 

Moore's system simply makes the communications protocol used by the 
communications framework to effect a remote method invocation transparent to a 
program issuing the remote method invocation . This is clearly not the same as, and 
does not teach or suggest, what is actually recited in claim 1. Furthermore, Moore's 
system may dynamically switch between RPC transports, which may be roughly 
analogous to the protocol block , but Moore is silent as to a presentation block , encoding 
block , and transport block as recited in claim 1. Contrary to the Examiner's assertion, 
Moore does not teach or suggest the limitation as recited in claim 1 . 

In further regard to claim 1, in the Action dated November 1, 2007, the 
Examiner asserts: 
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It would have been obvious... to modify the system of Lev Ran with the 
teaching of Moore because the teaching of Moore would improve the 
system of Lev Ran by providing a dynamic programming method of 
solving problems exhibiting the properties of overlapping subproblems 
and optimal substructure that takes much less time than naive methods. 

Applicants remind the Examiner that, to establish a prima facie case of 
obviousness of a claimed invention, all claim limitations must be taught or suggested by 
the prior art . In re Royka, 490 F.2d 981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP 
2143.03. As shown above, the cited art does not teach or suggest all limitations of claim 
1. Furthermore, the cited references alone or in combination clearly do not teach or 
suggest claim 1 when viewed as a whole: a remote procedure call system comprising a 
presentation block , an encoding block , a protocol block , and a transport block , wherein 
the functionality of each said block is isolated from the functionality of the other said 
blocks in the remote procedure call system so that program instructions for each said 
block can be replaced or modified without replacing or modifying program instructions 
for any of the other said blocks . Moreover, the Examiner's stated reason for combining 
Lev Ran and Moore is merely conclusory. Thus, the Examiner has not stated a proper 
reason to combine the teachings of the references in regard to the specific claimed 
combination. 

Furthermore, it is not at all clear that Lev Ran and Moore are combinable. 
In addition, even if Lev Ran and Moore were combinable, such a combination 
would not produce anything like was is recited in claim 1 of the instant application. 

Combining Lev Ran's "double-proxy remote data access system" with Moore's 
communications framework that allows dynamic switching between RPC transports 
"transparent to the programs issuing the remote method invocation" might, if possible, 
enable Lev Ran's system to dynamically switch between RPC transports; however, such 
a combination would not produce anything like was is actually recited in claim 1 of 
the instant application when viewed as a whole. 
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Thus, for at least the reasons presented above, the rejection of claim 1 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
as those above regarding claim 1 also apply to claims 23, 34, 36 and 47. 

Regarding claim 2, since claim 2 depends from claim 1, Applicant traverses 
this rejection for at least the reasons given above in regard to claim 1. 

In further regard to claim 2, contrary to the Examiner's assertion, the cited 
art fails to disclose wherein the protocol block is further configured to determine the 
intent of the encoded and protocol framed incoming messages. The Examiner cites Lev 
Ran, col. 61, lines 53-59 in support of this assertion. Again, the Examiner appears to 
equate "RPC protocol manager" with protocol block as disclosed in claim 2 of the instant 
application. Applicant can find nothing in the citation provided by the Examiner that 
teaches or suggests anything like a protocol block configured to determine the intent of 
the encoded and protocol framed incoming messages . Lev Ran's RPC protocol manager 
"handles network conditions"; it is not described as performing any task similar to 
deterininfing] the intent of the encoded and protocol framed incoming messages . 

In further regard to claim 2, contrary to the Examiner's assertion, the cited 

art fails to teach wherein the presentation block is further configured to provide the 

data types from the incoming messages to the program on the system. The Examiner 

cites Lev Ran, col. 56, lines 16-25 in support of this assertion, and appears to equate 

". . .response messages. . ." with "data types from the incoming messages." The context of 

that snipped quote from Lev Ran is: 

Remote services are activated by bidirectionally transferring remote 
procedure call (RPC) messages between a client application transport 
layer ("RPC client") on one VFN gateway and a server application 
transport layer ("RPC server") on a second remote VFN gateway. 
Preferably, the application transport layer functions asymmetrically, 
whereby the RPC client sends RPC request messages to the RPC server, 
and the RPC server responds by sending RPC response messages to the 
RPC client. 
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The above citation does not teach or suggest anything like a presentation block 
[that] is... configured to provide the data types from... incoming messages to [a] 
program on the system. In the citation, the RPC response messages are sent from an 
RPC server to an RPC client in response to RPC request messages sent by the RPC client 
to the RPC server. An RPC client is a "client application transport layer... on one VFN 
gateway." Lev Ran further describes the client application transport layer (RPC client) 
beginning at col. 61, line 20. Note that the RPC client is clearly disclosed as a 
component of Lev Ran's VFN system, and not as a program separate from the system. 
The RPC client and RPC server components exchange RPC request and RPC response 
messages internal to Lev Ran's VFN system. Neither one of the components is described 
as providing the data types from incoming messages to a program on the system. 

In the Action dated May 15, 2007, in response to the above argument, the 

Examiner again asserts "the 'java object/object class or type' passed in an RPC 
request/response describes the data type passed between remote systems as the instant 
application discloses." Applicant refers the Examiner to the Applicant's responses to this 
argument in regards to claim 1. Furthermore, Applicant again notes that the RPC 
response messages are sent from an RPC server to an RPC client in response to 
RPC request messages sent by the RPC client to the RPC server. The RPC client 
and RPC servers are clearly disclosed as components of Lev Ran's VFN system, and 
neither is disclosed as "a program separate from the system". The RPC client and 
RPC server components exchange RPC request and RPC response messages 
internal to Lev Ran's VFN system . Neither one of the components is described as 
providing the data types from incoming messages to a program on the system . 
Furthermore, in claim 2, it is clearly recited that the receiving of messages from a 
"remote system" is handled by the transport block of the remote procedure call system, 
and not by the presentation block of the remote procedure call system. The presentation 
block is instead configured to provide the data types from the incoming messages to the 
program on the system . Furthermore, the "program on the system" in claim 2 is clearly 
and distinctly a different entity than the "remote system" from which incoming messages 
are received by the transport block . 
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Thus, for at least the reasons presented above, the rejection of claim 2 is not 
supported by the cited art and removal thereof is respectfully requested. Similar remarks 
as those above regarding claim 2 also apply to claims 26, 35, 39 and 50. 

The Examiner rejected claim 3 as being unpatentable over Lev Ran in view of 
Moore as applied to claim 2 above, and further in view of Merrick, et al. (U.S. Patent 
7,028,312) (hereinafter "Merrick"). Since claim 3 depends from claim 2, Applicant 
traverses this rejection for at least the reasons given above in regard to claim 2. 

In further regard to claim 3, contrary to the Examiner's assertion, the cited 
art alone or in combination fails to teach to determine the intent of the encoded and 
protocol framed incoming messages, the protocol block is further configured to 
determine if the incoming messages are reqeuest messages or response messages. The 

Examiner notes that Lev Ran is silent on to determine the intent of the encoded and 
protocol framed incoming messages, the protocol block is further configured to 
determine if the incoming messages are reqeuest messages or response messages, and 
asserts that Merrick teaches that limitation. In support of that assertion, the Examiner 
cites Merrick, col. 14, lines 11-14, and quotes from that selection ". . .interprets. . .". That 
citation states: 

As shown in step 2, the server interprets the request message as a request 
to perform a particular service and performs the service. 

Applicant fails to see how the provided citation from Merrick that teaches a 
server interprets a request message as a request to perform a particular service is 

supposed to teach or suggest the limitiation of to determine the intent of the encoded and 
protocol framed incoming messages, the protocol block is further configured to 
determine if the incoming messages are reqeuest messages or response messages, as 
recited in claim 3. The citation does not teach or suggest anything along the lines of 
determining if incoming messages are request messages or response messages. Further, 
the provided citation just says a "server" interprets the request message, and mentions 
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nothing about a "protocol block" configured to determine the intent of incoming 
messages (e.g., as to whether the incoming messages are request messages or response 
messages). 

In the Final Office Action dated May 15, 2007, in response to the above 

argument, the Examiner asserts "claim 3 requires a determination as to whether a 

particular message is a request message or response message. The Server of the Merrick 

prior art covers this limitation by functioning to interpret a message as request message 

and performing a particular service as a result of his determination." However, the 

citation from Merrick does not teach what the Examiner asserts. A more complete 

citation from Merrick (col. 14, lines 4-15) reads: 

FIG. 4 illustrates this process for the case where the transfer protocol is 
one of HTTP, SMTP, or FTP and the messages arc transmitted across the 
Internet. According to the XML RPC procedure, and as depicted in step 1 
of the figure, a client uses the transfer protocol to send an XML-based 
message to a server. This message is known as the request message . 
When HTTP is the transfer protocol, it is natural to accomplish this via 
HTTP's POST method. As shown in step 2, the server interprets the 
request message as a request to perform a particular service and performs 
the service. The server may perform this service using information found 
in the request message. 

From the above, it is clear that when the server receives the request message, the 
request message is "known as the request message". Merrick's server does not have to 
determine if the incoming request message is a reqeuest message or a response 
message. Merrick's server would obviously already know that the incoming request 
message is a request message. What Merrick teaches in this citation is that the server 
" interprets the request message [already recognizing the request message as a request 
message, and thus clearly not having to determine if the incoming message is a reqeuest 
message or a response message] as a request to perform a particular service and 
performs the service." In other words, Merrick's server interprets the request message 
as a particular request message to perform a particular service. The Examiner's assertion 
that "The Server of the Merrick prior art covers this limitation by functioning to 
interpret a message as request message and performing a particular service as a result 
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of his determination" is without merit. The cited art alone or in combination, do not 
teach or suggest anything like a protocol block that is further configured to determine if 
the incoming messages are reqeuest messages or response messages. 

In the Final Office Action dated May 15, 2007, in response to the above 

argument, the Examiner goes on to assert "As for Merrick prior art not teaching the 

phrase 'protocol block', the test for whether a particular limitation is met is determining 

if the functionalities of the claim are met by that of the reference(s) used. In this instance 

the test is not whether the cited references disclose the phrase 'protocol block', but 

whether they teach the functionality of the claim limitation and the Examiner is 

convinced that the passage used in the rejection cover this limitation. This 

notwithstanding, the fact both request and response messages are disclosed makes it 

inherent that there must be way of differentiating them, otherwise the system would not 

differentiate when it delivering request message from it is delivering a response 

message." The rest of the above citation from Merrick (col. 14, lines 15-19) reads: 

When the service completes, the server generates a reply message . The 
reply message may contain information describing the results of the 
service. In step 3 the server then transmits the reply message to the client 
that initiated the request . 

Merrick's server is described in the cited paragraph and elsehwere as receiving 
request messages and generating and sending reply (response) messages . There would 
be no need in Merrick's described server to determine if the incoming messages are 
reqeuest messages or response messages. As noted above, incoming messages to a 
server in Merrick are request messages. The server generates and sends reply (response) 
messages. The Examiner's assertion that "the fact both request and response messages 
are disclosed makes it inherent that there must be way of differentiating them, otherwise 
the system would not differentiate when it delivering request message from it is 
delivering a response message" is without merit. 

The Examiner goes on to assert that "it would have been obvious. . .to modify the 
system of Lev Ran with the teaching of Merrick because the teaching of Merrick would 
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improve the system of Lev Ran by providing a process for determining the appropriate 

output arguments for a returning responses to a client program", and cites Merrick, col. 

14, lines 34-37. That citation reads as follows: 

The client must also associate reply messages received with request 
messages sent so that it can return the appropriate output arguments from 
the service that the client program invoked. 

Applicant notes that the first citation (Merrick, col. 14, lines 11-14), which refers 
to a server interpreting request messages as requests to perform particular services 
and performing the services [indicated by the request messages], appears to have little if 
anything to do with the second citation (Merrick, col. 14, lines 34-37), which addresses 
the need for a client to associate received reply messages with sent request messages. In 
other words, the first citation from Merrick does not "provide a process for determining 
the appropriate output arguments for a returning responses to a client program", as the 
Examiner appears to be asserting. 

In the Final Office Action dated May 15, 2007, in response to the above 
argument, the Examiner asserts "the motivation for combining the Lev Ran and Merrick 
prior arts is drawn from column 14 lines 34-37 of the Merrick prior art. This passage is 
related to the determining step of claim 3 because in determining the type of message, in 
this case a request message, the server then knows the type of response to return to the 
client." The Examiner's argument here is quite confusing, and makes no sense in light of 
the Merrick disclosure. Merrick's server does not have to determine if incoming 
messages are reqeuest messages or response messages. Merrick's server receives 
request messages from Merrick's client and sends reply (response) message to Merrick's 
client. Merrick's server obviously knows that a received reqeust message from a client 
is a request message. There is obviously no need in Merrick for the server to determine 
if the received request message is a request message or a response message. Likewise, 
Merrick's client does not have to determine if incoming messages are reqeuest 
messages or response messages. Merrick's client receives response (reply) messages 
from Merrick's server and sends request messages to Merrick's server. Merrick clearly 
does not teach or even suggest the limitation as recited in claim 3 of the instant 
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application. The Examiner asserts "in determining the type of message, in this case a 
request message, the server then knows the type of response to return to the client." 
Merrick's server does not have to determine that an incoming request message is a 
request message. The cited selection from Merrick simply discloses that Merrick's server 
"interprets" a request message to determine what the particular request indicated 
by the request message is, and does not teach or suggest that the server (or the client) 
does anything like determining if incoming messages are reqeuest messages or response 
messages. 

Merrick, alone or in combination with Lev Ran, does not teach or suggest what 
the Examiner asserts it teaches in regards to claim 3. Furthermore, even if Merrick, 14, 
lines 11-14 did teach what the Examiner asserts it teaches, combining Merrick with Lev 
Ran would not solve the problem that the Examiner asserts it would solve. Furthermore, 
combining the cited references would not produce anything like what is recited in claim 3 
of the instant application. 

Thus, for at least the reasons presented above, the rejection of claim 3 is not 
supported by the cited art and removal thereof is respectfully requested. 

Applicant also asserts that the rejection of numerous ones of the dependent claims 
is further unsupported by the cited art. However, since the rejections have been shown to 
be unsupported for the independent claims, a further discussion of the dependent claims 
is not necessary at this time. 
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CONCLUSION 



Applicant submits the application is in condition for allowance, and notice to that 
effect is respectfully requested. 



If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
64301/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Applicant 
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